<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="zh" xml:lang="zh" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Guideline: 业务架构文档</title>
<meta name="uma.type" content="Guideline">
<meta name="uma.name" content="business_architecture_document">
<meta name="uma.presentationName" content="业务架构文档">
<meta name="element_type" content="other">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="1.2153147493608049E-305"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Guideline: 业务架构文档</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/guidance.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">构建业务架构时，考虑了对关键业务流程进行最佳改进或改造所需的机制。本指南描述组成完整的业务架构文档的内容。</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Related Elements</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../rup_bm/tasks/bm_prioritize_use_cases_B1D2ADEE.html" guid="_31oH4BpWEdqUwb9RAn2tTA">划分业务用例的优先级</a>
</li>
<li>
<a href="./../../../rup_bm/tasks/bm_architectural_analysis_630ADB6.html" guid="_xfhhcBpWEdqUwb9RAn2tTA">业务架构分析</a>
</li>
<li>
<a href="./../../../nup_base/workproducts/rup_business_architecture_document_patch_FFF763B3.html" guid="_hcjIMNYNEd255dRY2gdxDg">业务架构文档</a>
</li>
<li>
<a href="./../../../rup_bm/domains/business_modeling_rup_CDDF8485.html" guid="_8loI0CuREdqL6tsHh4YXGw">业务建模</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><a id="Top" name="Top"></a><a key="业务架构文档（Business Architecture Document）" text="指南" name="XE_Business_Architecture_Document__guidelines_for" id="XE_Business_Architecture_Document__guidelines_for" class="index"></a> 
<h3>
    <a id="References" name="References">引用</a>
</h3>
<p>
    “业务架构文档”的“引用”一节提供了包含对于理解业务架构起重要作用的背景信息的外部文档。若有大量引用，将该节组织为若干子节，例如：
</p>
<ul>
    <li>
        外部文档
    </li>
    <li>
        内部文档
    </li>
    <li>
        政府文档
    </li>
    <li>
        非政府文档
    </li>
</ul>
<h3>
    <a id="Architectural Drivers" name="Architectural Drivers">架构推动因素<img height="20" alt="回到页首"     src="./../../../rup/resources/top.gif" width="26" border="0" /></a>
</h3>
<p>
    业务架构是通过考虑改进或重新设计关键业务流程所需的机制来构成的。构成<a class="elementLink" href="./../../../rup_bm/workproducts/rup_business_use_case_model_EC79264C.html" guid="{89BEF367-5875-47E0-97D6-23E5BCCE52B8}">业务用例模型</a>子集的业务用例将代表这些流程。另一重要输入为业务目标，这也记录在<a class="elementLink" href="./../../../rup_bm/workproducts/rup_business_use_case_model_EC79264C.html" guid="{89BEF367-5875-47E0-97D6-23E5BCCE52B8}">业务用例模型</a>中。在此没有必要描述<i>所有</i>业务目标，因而仅描述重要的架构目标。以下是可确定某个业务目标是否为重要的架构目标的特征的示例：
</p>
<ul>
    <li>
        该目标对于企业取得长期成功至关重要。
    </li>
    <li>
        该目标对业务策略起重要作用。
    </li>
    <li>
        当前流程、资源和基础结构无法实现该目标。
    </li>
    <li>
        改变该目标可能对业务产生广泛的影响。
    </li>
    <li>
        业务无法直接控制的外部团体可影响该目标。
    </li>
</ul>
<p>
    但是，这些影响并不是形成业务架构的仅有因素。还存在由业务运作的环境、重复使用现有资产的需求、强制执行的多个标准等所强加的若干约束。由于这些宏观级别的力量（<b>推动因素</b>）对业务内容及其运作的方式有着重要影响，所以认为是它们形成了业务架构。
</p>
<p>
    <b>架构推动因素</b>是架构<b>目标</b>和<b>约束</b>的统称。架构目标描述业务架构的期望或意图，而架构约束强加限制。清楚地定义架构目标可使业务利用影响业务的力量；清楚地定义架构约束可减少限制备选方案所带来的风险。例如，要考虑策略焦点（运作优点、客户亲密度或产品革新）、人力资源或其他资源的可用性、当前及期望的经济情况、技术趋势、改变客户行为、竞争者动向、业务运作的市场的状态、全球化、经济走向以及立法与规程。
</p>
<p>
    还要考虑形成业务架构的关键的业务质量维度。提供的信息可以包括：
</p>
<ul>
    <li>
        运作性能需求
    </li>
    <li>
        质量目标，例如“按时交付所有产品”
    </li>
    <li>
        扩展性目标，例如满足增长的客户需求的能力
    </li>
    <li>
        可移植性目标，例如受支持的国家或地区、语言和产品线
    </li>
</ul>
<h3>
    <a id="The Business Process View" name="The Business Process View">业务进程视图</a>
</h3>
<p>
    包含关键业务流程的业务进程视图是<a class="elementLinkWithType" href="./../../../rup_bm/workproducts/rup_business_use_case_model_EC79264C.html" guid="{89BEF367-5875-47E0-97D6-23E5BCCE52B8}">Artifact: 业务用例模型</a>的一部分。 它描述了以下一系列的业务场景和业务用例：
</p>
<ul>
    <li>
        代表业务的某些重要核心能力的业务场景和业务用例
    </li>
    <li>
        涵盖丰富的内容，这意味着它们使用组织的许多关键元素
    </li>
    <li>
        强调或阐释业务架构的某个特定的、精细的、复杂的或有风险的要点的业务场景和业务用例
    </li>
</ul>
<p>
    美国审计总署 [<a class="elementLinkWithUserText" href="./../../../rup/customcategories/references_56F06DFD.html" guid="7.755968586980351E-308">GAO97</a>] 列出了按优先顺序对业务流程排序的一定标准：
</p>
<ul>
    <li>
        与业务策略有最强链接的流程
    </li>
    <li>
        对客户影响最大的流程
    </li>
    <li>
        有最大的潜在改进回报的流程
    </li>
    <li>
        对变更需求意见完全一致的流程
    </li>
    <li>
        可使用当前可用的资源和基础结构进行重新设计的流程
    </li>
    <li>
        可被快速改进的不太复杂的流程（速效方案）
    </li>
    <li>
        可用于在重新设计中获取经验的不太复杂的流程
    </li>
</ul>
<p>
    每个重要的业务用例都包含一个包含以下信息的子节：
</p>
<ul>
    <li>
        业务用例的名称
    </li>
    <li>
        对业务用例的简短描述，其中包括用例目的
    </li>
    <li>
        为何认为业务用例在架构方面十分重要的<i>原因</i>描述
    </li>
</ul>
<h3>
    <a id="The Organization Structure View" name="The Organization Structure View">组织视图</a>
</h3>
<p>
    组织视图最初是<a class="elementLinkWithType" href="./../../../rup_bm/workproducts/rup_business_analysis_model_9449F63A.html" guid="{CF53445C-3351-46C6-810E-8251830029A7}">Artifact: 业务分析模型</a>的一部分，包括对于业务架构十分重要的元素。业务分析模型优化为<a class="elementLinkWithType" href="./../../../rup_bm/workproducts/rup_business_design_model_E75F0498.html" guid="_Yi4dsBpWEdqUwb9RAn2tTA">Artifact: 业务设计模型</a>后，组织视图也随之转变，以显示业务中的抽象角色如何与人员、软件和硬件绑定。这使您能够对业务运作性能和成本进行数量上的推理。
</p>
<p>
    组织视图描述最重要的业务工作者、业务实体和业务事件、它们在各个业务系统中的分组以及它们在各层中的组织。它还包括最重要的业务用例实现和对行为的一般模式的描述。
</p>
<p>
    该视图的范围可以是业务本身（内部组织）或是业务及其与伙伴的关系（扩展的组织）。若您要考虑向客户交付产品和服务过程中涉及的整个价值链，那么就要特别注意后一种观点。
</p>
<h3>
    <a id="Human Resources Aspects View" name="Human Resources Aspects View">人力资源视图</a>
</h3>
<p>
    人力资源视图包括组织变更准备工作的所有方面。结果包括：
</p>
<ul>
    <li>
        建议的基础结构
    </li>
    <li>
        激发员工在改变后的组织中进行工作的机制
    </li>
    <li>
        在改变后的组织中促进必要的技能的机制
    </li>
</ul>
<p>
    为了快速地实现运作良好的组织，在最终业务设计的完成很早以前就可开始该工作。在项目早期，工作目标稳定之前的初始迭代中，工作的重点通常在于使员工对改变有所准备。在项目后期，工作的重点变为对新任务中的雇员进行培训以及调查改变基础结构的需求；例如，人们所在的位置和他们需要的设备。若业务建模工作导致大量的改变，例如导致<a class="elementLinkWithUserText" href="./../../../rup/guidances/termdefinitions/business_reengineering_8A1CC1F0.html" guid="_x87h-dnmEdmO6L4XMImrsA">业务重新设计</a>，对改变的准备可能将是一项复杂且代价高的任务，以至于要将该工作作为单独的项目来对待。
</p>
<p>
    已被许多组织成功使用的 Kotter 的改变模型 [<a class="elementLinkWithUserText" href="./../../../rup/customcategories/references_56F06DFD.html" guid="7.755968586980351E-308">KOT96</a>]
    为引导组织进行改变定义了下列步骤：
</p>
<ul>
    <li>
        形成紧迫感。
    </li>
    <li>
        建立引导联合。
    </li>
    <li>
        设定愿景和策略。
    </li>
    <li>
        传达愿景。
    </li>
    <li>
        为基于大范围的操作提供能力支持。
    </li>
    <li>
        生成“速效方案”。
    </li>
    <li>
        巩固成果并进行更多的改变。
    </li>
    <li>
        使新方法制度化。
    </li>
</ul>
<p>
    更具体地说，您需要考虑更改的以下方面：
</p>
<ul>
    <li>
        <a href="#Understanding Organizational Culture">理解组织文化</a>
    </li>
    <li>
        <a href="#Managing concerns and attitudes">管理关注点和态度</a>
    </li>
    <li>
        <a href="#Changing and improving skills">改变和提高技能</a>
    </li>
    <li>
        <a href="#Defining Incentives�">确定激励机制</a>
    </li>
</ul>
<h5>
    <a id="Understanding Organizational Culture" name="Understanding Organizational Culture">理解组织文化</a>
</h5>
<p>
    要利用改变取得成功并使之持久，您还必须理解并可能更改目标组织的文化。若未能理解目标组织的文化，任何<a class="elementLink" href="./../../../rup/guidances/termdefinitions/business_engineering_744E8794.html" guid="_x8onANnmEdmO6L4XMImrsA">业务工程（business engineering）</a>工作都将失败。&nbsp;
</p>
<p>
    即使您的业务建模工作并未针对任何根本的改变，充分理解文化也是非常重要的，它可避免为组织引进的元素以某种始料未及的方式扰乱组织。&nbsp;
</p>
<p>
    文化并不是某种可触及或用简单的公式就可描述的东西。&nbsp;
</p>
<p>
    Champy [<a class="elementLinkWithUserText" href="./../../../rup/customcategories/references_56F06DFD.html" guid="7.755968586980351E-308">CHM95</a>] 将健全企业的文化描述为一种“自发自动”的文化。Champy 还特别提出新业务中的雇员必须愿意：
</p>
<ul>
    <li>
        始终以最高的能力来执行工作
    </li>
    <li>
        积极主动并承担风险
    </li>
    <li>
        适应改变
    </li>
    <li>
        作出决策
    </li>
    <li>
        作为团队合作
    </li>
    <li>
        具有开放的态度，特别是在对待信息、知识以及有关目前或即将出现的“问题”时
    </li>
    <li>
        信任他人且自身是可靠的
    </li>
    <li>
        尊重他人，包括客户、供应者、同事及自身
    </li>
    <li>
        对其行为负责并承担职责
    </li>
    <li>
        根据绩效作出判断和接受评价，作出奖励和接受奖励
    </li>
</ul>
<p>
    改变企业文化或就此而言的任何文化并非易事。就这一点是全部书刊的主题。此外，Champy [<a class="elementLinkWithUserText" href="./../../../rup/customcategories/references_56F06DFD.html" guid="7.755968586980351E-308">CHM95</a>]
    提供了对所建议过程的简短描述的启示：
</p>
<ul>
    <li>
        确定现有企业中人员的共享价值。
    </li>
    <li>
        确定并清除坏的行为。
    </li>
    <li>
        清楚地表达您想要的价值和行为。
    </li>
    <li>
        确定管理用例是否支持您对某些价值和行为的期望。若不支持，则不可能改变文化。
    </li>
    <li>
        通过按照新价值传授、行动和生存，来融入新价值。
    </li>
</ul>
<p>
    在通往改变后文化的道路上陷阱密布。此处重申 Champy [<a class="elementLinkWithUserText" href="./../../../rup/customcategories/references_56F06DFD.html" guid="7.755968586980351E-308">CHM95</a>] 中所警告的四个“不要”：
</p>
<ul>
    <li>
        不要容忍那些拒绝改变其行为的人，尤其是在他们的工作对于完成工程目标起重要作用的情况下。当容忍旧的行为时，这将表示您对改变并不严肃。这适用于每个人，经理和团队成员都一样。
    </li>
    <li>
        除非您安排人们的工作让他们可以有不同行动，否则不要期望人们改变其行为方式。
    </li>
    <li>
        不要期望快速的文化改变。完全的文化改变需要数年时间，而不是几个月。
    </li>
    <li>
        不要延迟设计管理用例以支持价值的新集合。
    </li>
</ul>
<h5>
    <a id="Managing concerns and attitudes" name="Managing concerns and attitudes">管理关注点和态度</a>
</h5>
<p>
    要考虑的范围包括：
</p>
<ul>
    <li>
        业务观念和策略 － 对它们作出了充分说明吗？每个人都可理解吗？&nbsp;
    </li>
    <li>
        面向功能的组织与面向流程的组织 － 是要改变为面向流程的组织吗？在这种情况下，对益处进行说明了吗？可理解这些益处吗？
    </li>
    <li>
        即将来临的改变 － 若对改变必需的以及激发改变的因素进行了说明，改变就会少些威胁性。不仅应从企业成员的角度激发改变，还应从客户的角度激发改变。&nbsp;
    </li>
    <li>
        企业文化 － 文化支持所提议的改变吗？&nbsp;
    </li>
</ul>
<h5>
    <a id="Changing and improving skills" name="Changing and improving skills">改变和提高技能</a>
</h5>
<p>
    有必要在若干级别进行培训，我们选择了显示三个类别。对于一般技能和某些特定于领域的技能，您可能会找到外部提供的程序。对于更特定于您的组织的技能，您需要开发和计划演示、研讨会以及在某些情况下的更广泛的培训方案。&nbsp;
</p>
<p>
    一般技能：
</p>
<ul>
    <li>
        面向流程的组织针对于客户。您可能需要在向客户交付价值和完全遵循过程之间形成差异意识。&nbsp;
    </li>
    <li>
        对在流程中工作的个人指定职责，这可能要求您明确每个人都充分清楚理解了业务规则以作出正确的决定。&nbsp;
    </li>
</ul>
<p>
    特定于域的技能：
</p>
<ul>
    <li>
        您对业务（包括产品和服务）总体了解吗？
    </li>
    <li>
        涉及了哪些业务参与者（客户、伙伴、供应者）？
    </li>
    <li>
        产生的结果以及交付的服务是什么？
    </li>
    <li>
        这与您在流程中的工作职责是如何关联的？
    </li>
</ul>
<p>
    特定于业务流程的技能：
</p>
<ul>
    <li>
        您需要对业务流程有充分的了解。
    </li>
    <li>
        您需要非常了解对您将要担任的业务工作者所确定的职责，并且有能力执行该业务工作者的任务。
    </li>
    <li>
        您需要了解同事的职责和任务。
    </li>
    <li>
        您需要了解如何使用业务工具。
    </li>
</ul>
<p>
    在组织内实现正确的技能可能是培训现有员工和聘用新人二者结合的结果。&nbsp;
</p>
<h5>
    <a id="Defining Incentivesnbsp;" name="Defining Incentives&nbsp;">确定激励机制</a>
</h5>
<p>
    定义奖励系统，该系统将激励员工朝业务观点和业务策略的方向工作以满足所服务的参与者的需求。对于单个业务流程的目标（作为起点，这些目标应基于业务观点和流程），定义与以下内容相关的奖励：
</p>
<ul>
    <li>
        业务整体性能
    </li>
    <li>
        业务流程的整体性能
    </li>
    <li>
        业务流程的单个执行（实例）的结果
    </li>
    <li>
        每个个体的贡献
    </li>
</ul>
<p>
    在目标组织中为所有种类的员工调查现有的激励。在面向功能的组织中，奖励通常与单个的功能组织单元相关，这种奖励法未能认识到业务的整体结果及其业务流程才是重要的方面。需要尽快取代这样的激励。
</p>
<p>
    然而，从旧的奖励系统到新的奖励系统的平滑转换对使员工接受改变而言是必要的。
</p>
<p>
    作为成功的先决条件，员工必须拥有正确的设备，且必须根据员工任务对该设备进行最佳安置。&nbsp;
</p>
<h3>
    <a id="Geographic View" name="Geographic View">地理视图<img height="20" alt="回到页首" src="./../../../rup/resources/top.gif"     width="26" border="0" /></a>
</h3>
<p>
    在服务行业中，最佳位置经常相对容易安排；而在制造公司中，业务流程中的改变可能既费钱又影响广泛。预算和可用的时间范围经常限制可能完成单个项目的因素。
</p>
<p>
    位置的重要性在不同种类的流程间有所变化。在这方面，电话销售流程、现场销售流程和制造流程有显著的差别。业务工程工作对将来在何处以及如何定位组织产生影响这一可能性也在项目间有着显著的差别。
</p>
<p>
    以下过程有助于确定一种实际的方法：
</p>
<ul>
    <li>
        查看每个业务用例，确定应如何对涉及的业务工作者进行实际定位以最优化地执行任务。
    </li>
    <li>
        逐个查看用例实现以确定每个业务工作者对设备和工作场地的需求。
    </li>
    <li>
        查看整个业务或一组相关的业务用例，并考虑： 
        <ul>
            <li>
                哪些业务工作者参与数个业务用例？
            </li>
            <li>
                哪些流程相互利用其他流程的结果？
            </li>
        </ul>
    </li>
    <li>
        将此作为基础来确定每个业务工作者的最佳位置。
    </li>
    <li>
        将此与当前情况比较，并自我提问： 
        <ul>
            <li>
                项目指令内的实际改变是什么？
            </li>
            <li>
                最具成本效率的位置是什么？
            </li>
            <li>
                什么是强制的？组织无需什么仍可存活？
            </li>
            <li>
                通过拥有正确的设备可弥补什么？
            </li>
            <li>
                通过拥有正确的位置可弥补什么？
            </li>
        </ul>
    </li>
    <li>
        考虑重新定位整个业务系统对业务用例的影响。
    </li>
    <li>
        评估每个业务用例的成本，根据发现的结论改变位置。确定投资是否实际。
    </li>
</ul>
<p>
    例如，销售人员在客户办公室时需要对公司数据库进行直接访问，那么就必须为他考虑移动数据解决方案。有时，安装视频会议设备可弥补开发团队的成员处于不同位置的这一不利情况。
</p>
<h3>
    <a id="Architectural Tradeoffs" name="Architectural Tradeoffs">架构权衡<img height="20" alt="回到页首"     src="./../../../rup/resources/top.gif" width="26" border="0" /></a>
</h3>
<p>
    “业务架构文档”的本节描述业务架构将如何实现在本文档开头附近描述的架构目标和约束（<b>架构推动因素</b>）。这是关于保持架构决策潜在的基本原理的讨论。大多数（至少许多）架构推动因素都相互冲突，因此业务架构必须提供一个最佳解决方案，该方案将在最大可能的程度上满足最大数目的、相互冲突的推动因素。这意味着必须作出权衡和决策。在此将对这些决策和权衡进行描述。
</p>
<p>
    作为示例，一个架构目标可能是快速部署新产品的能力，而另一个架构目标可能是通过合作伙伴作为补充产品交付产品的能力。由于通过外部合作伙伴交付产品意味着产品进入市场的时间会延迟，所以这两个目标相互冲突。在这种情况下，本节将描述为最大程度地实现这两个目标而在业务架构内所作的权衡。在该示例中，可能会组建一个合作伙伴产品管理团队，且可能会对候选合作伙伴的选择施加某些限制。
</p>
<p>
    仅当考虑了应用程序架构或技术架构后，将浮现许多冲突和权衡（请参阅<a class="elementLinkWithType" href="./../../../rup_bm/guidances/concepts/business_architecture_D437B035.html" guid="2.6275891002471178E-306">Concept: 业务架构</a>）。清楚地理解这些决策的结果是很重要的。
</p>
<p>
    本节提供了构建业务的整个架构轮廓的理由（如同最初在<a class="elementLinkWithType" href="./../../../rup_bm/workproducts/rup_business_analysis_model_9449F63A.html" guid="{CF53445C-3351-46C6-810E-8251830029A7}">Artifact: 业务分析模型</a>和<a class="elementLinkWithType" href="./../../../rup_bm/workproducts/rup_business_deployment_model_2392BF2E.html" guid="_lm_NMBpWEdqUwb9RAn2tTA">Artifact: 业务部署模型</a>获取的），以及选择实现人员、软件和硬件（在<a class="elementLinkWithType" href="./../../../rup_bm/workproducts/rup_business_design_model_E75F0498.html" guid="_Yi4dsBpWEdqUwb9RAn2tTA">Artifact: 业务设计模型</a>中提供）的理由 － 如果认为它们在架构方面很重要。
</p><br />
<br /></td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright"></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
